During the attack, the user is completely unaware that they received the SMS with the Simjacker Attack message, that information was retrieved, and that it was sent outwards in the Data Message SMS - there is no indication in any SMS inbox or outbox.
The attack relies both on these specific SMS messages being allowed, and the S@T Browser software being present on the UICC in the targeted phone. Specific SMS messages targeting UICC cards have been demonstrated before on how they could be exploited for malicious purposes. The Simjacker attack takes a different approach, and greatly simplifies and expands the attack by relying on the S@T Browser software as an execution environment. The S@T (pronounced sat) Browser – or SIMalliance Toolbox Browser to give it its full name – is an application specified by the SIMalliance, and can be installed on a variety of UICC (SIM cards), including eSIMs. This S@T Browser software is not well known, is quite old, and its initial purpose was to enable services such as getting your account balance through the SIM card. Globally, its function has been mostly superseded by other technologies, and its specification has not been updated since 2009, however, like many legacy technologies it is still been used while remaining in the background. In this case we have observed the S@T protocol being used by mobile operators in at least 30 countries whose cumulative population adds up to over a billion people, so a sizable amount of people are potentially affected. It is also highly likely that additional countries have mobile operators that continue to use the technology on specific SIM cards.
This attack is also unique, in that the Simjacker Attack Message could logically be classified as carrying a complete malware payload, specifically spyware. This is because it contains a list of instructions that the SIM card is to execute. As software is essentially a list of instructions, and malware is ‘bad’ software, then this could make the Simjacker exploit the** first real-life case of malware (specificially spyware) sent within a SMS.** Previous malware sent by SMS - such as the incidents we profiled here - have involved sending links to malware, not the malware itself within a complete message.
However, the novelty and potential of Simjacker does not stop there. Retrieving a person’s location is one thing, but by using the same technique, and by modifying the attack message, the attacker could instruct the UICC to execute a range of other attacks. This is because using the same method the attacker has access to a range* of STK command set, some examples of these STK commands are:
*Note: 25/09/19 - in the earlier version of this blog, a number of additional proactive STK commands were included above. Subsequent analysis has shown that these commands are unlikely to be actionable and so have been removed.
By using these commands in our own tests, we were able to make targeted handsets open up web browsers, ring other phones, send text messages and so on. These attacks could be used to fulfil such purposes as
It even may be possible to go even further - depending on handset type - which we will discuss in our VB2019 presentation. Worryingly, we are not the only people to think of these additional attacks, over the last few weeks and months we have observed the attackers themselves experiment with these different capabilities.
Finally, another benefit of Simjacker from the attacker’s perspective is that many of its attacks seems to work independent of handset types, as the vulnerability is dependent on the software on the UICC and not the device. We have observed devices from nearly every manufacturer being successfully targeted to retrieve location: Apple, ZTE, Motorola, Samsung, Google, Huawei, and even IoT devices with SIM cards. One important note is that for some specific attacks handset types do matter. Some, such as setting up a call, require user interaction to confirm, but this is not guaranteed and older phones or devices with no keypad or screens (such as IoT device) may not even ask for this.
The next question then is who is exploiting this, and why? We are quite confident that this exploit has been developed by a specific private company that works with governments to monitor individuals. As well as producing this spyware, this same company also have extensive access to the SS7 and Diameter core network, as we have seen some of the same Simjacker victims being targeted using attacks over the SS7 network as well, with SS7 attack methods being used as a fall-back method when Simjacker attacks do not succeed. So far, we have seen phone numbers from several countries being targeted by these attacks and we are very certain that individuals in other countries have also been targeted via Simjacker attacks. Using our collection of Signalling Intelligence (SIGIL) we were able to correlate this Simjacker-related SS7 activity with a group we have already detected attempting to attack targets via SS7 means around the world.
In one country we are seeing roughly 100-150 specific individual phone numbers being targeted per day via Simjacker attacks, although we have witnessed bursts of up to 300 phone numbers attempting to be tracked in a day, the distribution of tracking attempts varies. A few phone numbers, presumably high-value, were attempted to be tracked several hundred times over a 7-day period, but most had much smaller volumes. A similar pattern was seen looking at per-day activity, many phone numbers were targeted repeatedly over several days, weeks or months at a time, while others were targeted as a once-off attack. These patterns and the number of tracking indicates it is not a mass surveillance operation, but one designed to track a large number of individuals for a variety of purposes, with targets and priorities shifting over time. The ‘first use’ of the Simjacker method makes sense from this viewpoint, as doing this kind of large volume tracking using SS7 or Diameter methods can potentially expose these sources to detection, so it makes more sense to preserve those methods for escalations or when difficulties are encountered.
In order to deal with this vulnerability, we and the mobile industry have been taking a number of steps.
In general, our recommendations for the mobile community to deal with the immediate threat is for mobile operators to analyse and block suspicious messages that contain S@T Browser commands. Mobile Operators could also try to change the security settings of UICCs in the field remotely, or even uninstall and stop using the S@T Browser technology completely, but this may be slower and considerably more difficult to do. However, this is very much only a first step, due to the greater implications of the Simjacker attacks.
The existence of Simjacker at all means that we need to radically alter our mindset when it comes to the security of mobile core networks. We believe that the Simjacker attack evolved as a direct replacement for the abilities that were lost to mobile network attackers when operators started to secure their SS7 and Diameter infrastructure. But whereas successful SS7 attacks required specific SS7 knowledge (and access), the Simjacker Attack Message require a much broader range of specific SMS , SIM Card, Handset, Sim Toolkit , S@T Browser and SS7 knowledge to craft. This investment has clearly paid off for the attackers, as they ended up with a method to control any mobile phone in a certain country, all with only a $10 GSM Modem and a target phone number. In short, the advent of Simjacker means that attackers of mobile operators have invested heavily in new attack techniques, and this new investment and skillset means we should expect more of these kinds of complex attacks.
As a consequence, this means that we, in the mobile security community also need to improve our capabilities. For mobile operators, this also means that relying on existing recommendations will not be sufficient to protect themselves, as attackers like these will always evolve to try to evade what is put in place. Instead mobile operators will need to constantly investigate suspicious and malicious activity to discover ‘hidden’ attacks. We can and should expect other vulnerabilities and attacks that also evade existing defences to be discovered and abused. As the attackers have expanded their abilities beyond simply exploiting unsecured networks, to now cover a very complex mix of protocols, execution environments and technologies to launch attacks with, Operators will also need to increase their own abilities and investment in detecting and blocking these attacks.
We are only scratching the surface of Simjacker in this article. In our presentation at Virus Bulletin Conference, London, on the 3rd of October 2019 we will give more details on the format of the attacks, what the attackers do to attempt to evade detection and how they operate their system, along with a flavour of what has been their reaction since their attacks have been detected and blocked. We will also give our view on what we believe these attacks will evolve into next. We expect a reaction from this news being made public and we will present on what (if any) the public revelations have on their malicious activity.
The Simjacker exploit represent a huge, nearly Stuxnet-like, leap in complexity from previous SMS or SS7/Diameter attacks, and show us that the range and possibility of attacks on core networks are more complex than we could have imagined in the past. Now is the time to make sure that we stay ahead of these attacks in the future.